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Abstract 


This document defines a method, INFO, for the Session Initiation 
Protocol (SIP), and an Info Package mechanism. This document 
obsoletes RFC 2976. For backward compatibility, this document also 
Specifies a "legacy" mode of usage of the INFO method that is 
compatible with the usage previously defined in RFC 2976, referred to 
as "legacy INFO Usage" in this document. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6086. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
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1. Introduction 


This document defines a method, INFO, for the Session Initiation 
Protocol (SIP) [RFC3261]. 


The purpose of the INFO message is to carry application level 
information between endpoints, using the SIP dialog signaling path. 
Note that the INFO method is not used to update characteristics of a 
SIP dialog or session, but to allow the applications that use the SIP 
session to exchange information (which might update the state of 
those applications). 


Use of the INFO method does not constitute a separate dialog usage. 
INFO messages are always part of, and share the fate of, an invite 
dialog usage [RFC5057]. INFO messages cannot be sent as part of 
other dialog usages, or outside an existing dialog. 


This document also defines an Info Package mechanism. An Info 
Package specification defines the content and semantics of the 
information carried in an INFO message associated with the Info 
Package. The Info Package mechanism also provides a way for user 
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agents (UAs) to indicate for which Info Packages they are willing to 
receive INFO requests, and which Info Package a specific INFO request 
is associated with. 


A UA uses the Recv-Info header field, on a per-dialog basis, to 
indicate for which Info Packages it is willing to receive INFO 
requests. A UA can indicate an initial set of Info Packages during 
dialog establishment and can indicate a new set during the lifetime 
of the invite dialog usage. 


NOTE: A UA can use an empty Recv-Info header field (a header field 
without a value) to indicate that it is not willing to receive 
INFO requests for any Info Package, while still informing other 
UAs that it supports the Info Package mechanism. 


When a UA sends an INFO request, it uses the Info-Package header 
field to indicate which Info Package is associated with the request. 
One particular INFO request can only be associated with a single Info 
Package. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Motivation 


A number of applications, standardized and proprietary, make use of 
the INFO method as it was previously defined in RFC 2976 [RFC2976], 
here referred to as "legacy INFO usage". These include but are not 
limited to the following: 


o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part 
(ISUP) in SIP message bodies.  ITU-T and the Third Generation 
Partnership Project (3GPP) have specified similar procedures. 


o [ECMA-355] specifies the encapsulation of "QSIG" in SIP message 
bodies. 


o RFC 5022 [RFC5022] specifies how INFO is used as a transport 
mechanism by the Media Server Control Markup Language (MSCML) 
protocol. MSCML uses an option-tag in the Require header field to 
ensure that the receiver understands the INFO content. 


o RFC 5707 [RFC5707] specifies how INFO is used as a transport 
mechanism by the Media Server Markup Language (MSML) protocol. 
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o Companies have been using INFO messages in order to request fast 
video update. Currently, a standardized mechanism, based on the 
Real-time Transport Control Protocol (RTCP), has been specified in 
RFC 5168 [RFC5168]. 


o Companies have been using INFO messages in order to transport 
Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are 
proprietary and have not been standardized. 


Some legacy INFO usages are also recognized as being shortcuts to 
more appropriate and flexible mechanisms. 


Furthermore, RFC 2976 did not define mechanisms that would enable a 
SIP UA to indicate (1) the types of applications and contexts in 
which the UA supports the INFO method or (2) the types of 
applications and contexts with which a specific INFO message is 
associated. 


Because legacy INFO usages do not have associated Info Packages, it 
is not possible to use the Recv-Info and Info-Package header fields 
with legacy INFO usages. That is, a UA cannot use the Recv-Info 
header field to indicate for which legacy INFO usages it is willing 
to receive INFO requests, and a UA cannot use the Info-Package header 
field to indicate with which legacy INFO usage an INFO request is 
associated. 


Due to the problems described above, legacy INFO usages often require 
static configuration to indicate the types of applications and 
contexts for which the UAs support the INFO method, and the way they 
handle application information transported in INFO messages. This 
has caused interoperability problems in the industry. 


To overcome these problems, the SIP Working Group has spent 
Significant discussion time over many years coming to agreement on 
whether it was more appropriate to fix INFO (by defining a 
registration mechanism for the ways in which it was used) or to 
deprecate it altogether (with the usage described in RFC 3398 
[RFC3398] being grandfathered as the sole legitimate usage). 
Although it required substantial consensus building and concessions 
by those more inclined to completely deprecate INFO, the eventual 
direction of the working group was to publish a framework for 
registration of Info Packages as defined in this specification. 


3. Applicability and Backward Compatibility 
This document defines a method, INFO, for the Session Initiation 


Protocol (SIP) [RFC3261], and an Info Package mechanism. This 
document obsoletes RFC 2976 [RFC2976]. For backward compatibility, 
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this document also specifies a "legacy" mode of usage of the INFO 
method that is compatible with the usage previously defined in 
RFC 2976, here referred to as "legacy INFO Usage". 


For backward compatibility purposes, this document does not deprecate 
legacy INFO usages, and does not mandate users to define Info 
Packages for such usages. However: 


1. A UA MUST NOT insert an Info-Package header field in a legacy 
INFO request (as described in Section 4.2.1, an INFO request 
associated with an Info Package always contains an Info-Package 
header field). 


2. Any new usage MUST use the Info Package mechanism defined in this 
Specification, since it does not share the issues associated with 


legacy INFO usage, and since Info Packages can be registered with 
IANA. 


3. UAs are allowed to enable both legacy INFO usages and Info 
Package usages as part of the same invite dialog usage, but UAs 
SHALL NOT mix legacy INFO usages and Info Package usages in order 
to transport the same application level information. If 
possible, UAs SHALL prefer the usage of an Info Package. 


4. The INFO Method 

4.1. General 
The INFO method provides a mechanism for transporting application 
level information that can further enhance a SIP application. 
Section 8 gives more details on the types of applications for which 


the use of INFO is appropriate. 


This section describes how a UA handles INFO requests and responses, 
as well as the message bodies included in INFO messages. 


4.2. INFO Request 
4.2.1. INFO Request Sender 


An INFO request can be associated with an Info Package (see 
Section 5), or associated with a legacy INFO usage (see Section 2). 


The construction of the INFO request is the same as any other 


non-target refresh request within an existing invite dialog usage as 
described in Section 12.2 of RFC 3261. 
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4 


.2 


When a UA sends an INFO request associated with an Info Package, it 
MUST include an Info-Package header field that indicates which Info 
Package is associated with the request. A specific INFO request can 
be used only for a single Info Package. 


When a UA sends an INFO request associated with a legacy INFO usage, 
there is no Info Package associated with the request, and the UA MUST 
NOT include an Info-Package header field in the request. 


The INFO request MUST NOT contain a Recv-Info header field. A UA can 
only indicate a set of Info Packages for which it is willing to 
receive INFO requests by using the SIP methods (and their responses) 
listed in Section 5. 


A UA MUST NOT send an INFO request outside an invite dialog usage and 
MUST NOT send an INFO request for an Info Package inside an invite 
dialog usage if the remote UA has not indicated willingness to 
receive that Info Package within that dialog. 


If a UA receives a 469 (Bad Info Package) response to an INFO 
request, based on RFC 5057 [RFC5057], the response represents a 
Transaction Only failure, and the UA MUST NOT terminate the invite 
dialog usage. 


Due to the possibility of forking, the UA that sends the initial 
INVITE request MUST be prepared to receive INFO requests from 
multiple remote UAs during the early dialog phase. In addition, the 
UA MUST be prepared to receive different Recv-Info header field 
values from different remote UAs. 


NOTE: If the User Agent Server (UAS) (receiver of the initial 
INVITE request) sends an INFO request just after it has sent the 
response that creates the dialog, the UAS needs to be prepared for 
the possibility that the INFO request will reach the User Agent 
Client (UAC) before the dialog-creating response, and might 
therefore be rejected by the UAC. In addition, an INFO request 
might be rejected due to a race condition, if a UA sends the INFO 
request at the same time that the remote UA sends a new set of 
Info Packages for which it is willing to receive INFO requests. 


.2. INFO Request Receiver 


If a UA receives an INFO request associated with an Info Package that 
the UA has not indicated willingness to receive, the UA MUST send a 
469 (Bad Info Package) response (see Section 11.6), which contains a 
Recv-Info header field with Info Packages for which the UA is willing 
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to receive INFO requests. The UA MUST NOT use the response to update 
the set of Info Packages, but simply to indicate the current set. In 
the terminology of multiple dialog usages [RFC5057], this represents 

a Transaction Only failure, and does not terminate the invite dialog 

usage. 


If a UA receives an INFO request associated with an Info Package, and 
the message body part with Content-Disposition "Info-Package" (see 
Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) 
type that the UA supports but not in the context of that Info 
Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media 
Type) response. 


The UA MAY send other error responses, such as Request Failure (4xx), 
Server Failure (5xx), and Global Failure (6xx), in accordance with 
the error-handling procedures defined in RFC 3261. 


Otherwise, if the INFO request is syntactically correct and well 
structured, the UA MUST send a 200 (OK) response. 


NOTE: If the application needs to reject the information that it 
received in an INFO request, that needs to be done on the 
application level. That is, the application needs to trigger a 
new INFO request, which contains information that the previously 
received application data was not accepted. Individual Info 
Package specifications need to describe the details for such 
procedures. 


4.2.3. SIP Proxies 


Proxies need no additional behavior beyond that described in RFC 3261 
to support INFO. 


4.3. INFO Message Body 
4.3.1. INFO Request Message Body 
The purpose of the INFO request is to carry application level 
information between SIP UAs. The application information data is 
carried in the payload of the message body of the INFO request. 
NOTE: An INFO request associated with an Info Package can also 


include information associated with the Info Package using 
Info-Package header field parameters. 


Holmberg, et al. Standards Track [Page 8] 


RFC 6086 INFO Framework January 2011 


If an INFO request associated with an Info Package contains a message 
body part, the body part is identified by a Content-Disposition 
header field "Info-Package" value. The body part can contain a 
single MIME type, or it can be a multipart [RFC5621] that contains 
other body parts associated with the Info Package. 


UAs MUST support multipart body parts in accordance with RFC 5621. 


NOTE: An INFO request can also contain other body parts that are 
meaningful within the context of an invite dialog usage but are 
not specifically associated with the INFO method and the 
application concerned. 


When a UA supports a specific Info Package, the UA MUST also support 
message body MIME types in accordance with that Info Package. 
However, in accordance with RFC 3261, the UA still indicates the 
supported MIME types using the Accept header. 


4.3.2. INFO Response Message Body 
A UA MUST NOT include a message body associated with an Info Package 
in an INFO response. Message bodies associated with Info Packages 


MUST only be sent in INFO requests. 


A UA MAY include a message body that is not associated with an Info 
Package in an INFO response. 


4.4. Order of Delivery 
The Info Package mechanism does not define a delivery order 


mechanism. Info Packages can rely on the CSeq header field [RFC3261] 
to detect if an INFO request is received out of order. 


If specific applications need additional mechanisms for order of 
delivery, those mechanisms, and related procedures, are specified as 
part of the associated Info Package (e.g., the use of sequence 
numbers within the application data). 


5. Info Packages 
5.1. General 


An Info Package specification defines the content and semantics of 
the information carried in an INFO message associated with an Info 
Package. The Info Package mechanism provides a way for UAs to 
indicate for which Info Packages they are willing to receive INFO 
requests, and with which Info Package a specific INFO request is 
associated. 
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5.2. User Agent Behavior 
5.2.1. General 


This section describes how a UA handles Info Packages, how a UA uses 
the Recv-Info header field, and how the UA acts in re-INVITE rollback 
situations. 


5.2.2. UA Procedures 


A UA that supports the Info Package mechanism MUST indicate, using 
the Recv-Info header field, the set of Info Packages for which it is 
willing to receive INFO requests for a specific session. A UA can 
list multiple Info Packages in a single Recv-Info header field, and 
the UA can use multiple Recv-Info header fields. A UA can use an 
empty Recv-Info header field, i.e., a header field without any header 
field values. 


A UA provides its set of Info Packages for which it is willing to 
receive INFO requests during the dialog establishment. A UA can 
update the set of Info Packages during the invite dialog usage. 


If a UA is not willing to receive INFO requests for any Info 
Packages, during dialog establishment or later during the invite 
dialog usage, the UA MUST indicate this by including an empty 
Recv-Info header field. This informs other UAs that the UA still 
supports the Info Package mechanism. 


Example: If a UA has previously indicated Info Packages "foo" and 
"bar" in a Recv-Info header field, and the UA during the lifetime of 
the invite dialog usage wants to indicate that it does not want to 
receive INFO requests for any Info Packages anymore, the UA sends a 
message with an empty Recv-Info header field. 


Once a UA has sent a message with a Recv-Info header field containing 
a set of Info Packages, the set is valid until the UA sends a new 
Recv-Info header field containing a new, or empty, set of Info 
Packages. 


Once a UA has indicated that it is willing to receive INFO requests 
for a specific Info Package, and a dialog has been established, the 
UA MUST be prepared to receive INFO requests associated with that 
Info Package until the UA indicates that it is no longer willing to 
receive INFO requests associated with that Info Package. 


For a specific dialog usage, a UA MUST NOT send an INFO request 


associated with an Info Package until it has received an indication 
that the remote UA is willing to receive INFO requests for that Info 
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Package, or after the UA has received an indication that the remote 
UA is no longer willing to receive INFO requests associated with that 
Info Package. 


NOTE: When a UA sends a message that contains a Recv-Info header 

field with a new set of Info Packages for which the UA is willing 
to receive INFO requests, the remote UA might, before it receives 
the message, send an INFO request based on the old set of Info 


Packages. In this case, the receiver of the INFO requests 
rejects, and sends a 469 (Bad Info Package) response to, the INFO 
request. 


If a UA indicates multiple Info Packages that provide similar 
functionality, it is not possible to indicate a priority order of the 
Info Packages, or to indicate that the UA wishes to only receive INFO 
requests for one of the Info Packages. It is up to the application 
logic associated with the Info Packages, and particular Info Package 
Specifications, to describe application behavior in such cases. 


For backward compatibility purposes, even if a UA indicates support 
of the Info Package mechanism, it is still allowed to enable legacy 
INFO usages. In addition, if a UA indicates support of the INFO 
method using the Allow header field [RFC3261], it does not implicitly 
indicate support of the Info Package mechanism. A UA MUST use the 
Recv-Info header field in order to indicate that it supports the Info 
Package mechanism. Likewise, even if a UA uses the Recv-Info header 
field to indicate that it supports the Info Package mechanism, in 
addition the UA still indicates support of the INFO method using the 
Allow header. 


This document does not define a SIP option-tag [RFC3261] for the Info 
Package mechanism. However, an Info Package specification can define 
an option-tag associated with the specific Info Package, as described 
in Section 10.6. 


5.2.3.  Recv-Info Header Field Rules 


The text below defines rules on when a UA is required to include a 
Recv-Info header field in SIP messages. Section 7.1 lists the SIP 
methods for which a UA can insert a Recv-Info header field in 
requests and responses. 


o The sender of an initial INVITE request MUST include a Recv-Info 
header field in the initial INVITE request, even if the sender is 
not willing to receive INFO requests associated with any Info 
Package. 
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o The receiver of a request that contains a Recv-Info header field 
MUST include a Recv-Info header field in a reliable 18x/2xx 
response to the request, even if the request contains an empty 
Recv-Info header field, and even if the header field value of the 
receiver has not changed since the previous time it sent a 
Recv-Info header field. 


o A UA MUST NOT include a Recv-Info header field in a response if 
the associated request did not contain a Recv-Info header field. 


NOTE: In contrast to the rules for generating Session Description 
Protocol (SDP) answers [RFC3264], the receiver of a request is not 
restricted to generating its own set of Info Packages as a subset 
of the Info Package set received in the Info-Package header field 
of the request. 


As with SDP answers, the receiver can include the same Recv-Info 
header field value in multiple responses (18x/2xx) for the same 
INVITE/re-INVITE transaction, but the receiver MUST use the same 
Recv-Info header field value (if included) in all responses for the 
same transaction. 


5.2.4. Info Package Fallback Rules 


If the receiver of a request that contains a Recv-Info header field 
rejects the request, both the sender and receiver of the request MUST 
roll back to the set of Info Packages that was used before the 
request was sent. This also applies to the case where the receiver 
of an INVITE/re-INVITE request has included a Recv-Info header field 
in a provisional response, but later rejects the request. 


NOTE: The dialog state rollback rules for Info Packages might 
differ from the rules for other types of dialog state information 
(SDP, target, etc.). 


5.3. REGISTER Processing 


This document allows a UA to insert a Recv-Info header field in a 
REGISTER request. However, a UA SHALL NOT include a header value for 
a specific Info Package unless the particular Info Package 
specification describes how the header field value shall be 
interpreted and used by the registrar, e.g., in order to determine 
request targets. 
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Rather than using the Recv-Info header field in order to determine 
request targets, it is recommended to use more appropriate 
mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this 
document does not define a feature tag for the Info Package 
mechanism, or a mechanism to define feature tags for specific Info 
Packages. 


6. Formal INFO Method Definition 

6.1. INFO Method 
This document describes one new SIP method: INFO. This document 
replaces the definition and registrations found in RFC 2976 


[RFC2976]. 


This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. 


Header field where INFO 
Accept R o 
Accept 415 o 
Accept-Encoding R O 
Accept-Encoding 2XX [e 
Accept-Encoding 415 c 
Accept-Language R fe) 
Accept-Language 2xx o 
Accept-Language 415 o 
Accept-Resource-Priority 2xx,417 O 
Alert-Info = 
Allow R o 
Allow 405 m 
Allow r o 
Authentication-Info 2xx [e 
Authorization R o 
Call-ID [o m 
Call-Info o 
Contact - 
Content-Disposition [e 
Content-Encoding O 
Content-Language o 
Content-Length o 
Content-Type * 
CSeq G m 
Date o 
Error-Info 3xx-6xx o 
Expires - 
From [o m 
Geolocation R O 
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Geolocation-Error 


Max-Breadth 
Max-Forwards 
MIME-Version 
Min-Expires 
Organization 
Priority 
Privacy 


Proxy-Authenticate 
Proxy-Authenticate 
Proxy-Authorization 


Proxy-Require 
Reason 
Record-Route 
Record-Route 
Referred-By 


Request-Disposition 


Require 


Resource-Priority 


Retry-After 
Retry-After 
Retry-After 
Retry-After 
Route 
Security-Client 
Security-Server 
Security-Verify 
Server 

Subject 
Supported 
Supported 
Timestamp 

To 

Unsupported 
User-Agent 

Via 

Warning 


WWW-Authenticate 
WWW-Authenticate 


Holmberg, et al. 


Table 1: 


INFO Framework 


DE 
lOO 10 


zal 
| 


" 
OD 0 O 00 0G Ou 


R 
404,413,480,486 
500,503 
600, 603 

R 
R 
421,494 


(w/ Tag) 


401 
407 


W 
O 3 © 3-00 8 O00 0 0 0 0 0 0.0 0 0 


Summary of Header Fields 


Standards Track 


January 2011 


[Page 14] 


RFC 6086 INFO Framework January 2011 


7. INFO Header Fields 
7.1. General 
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. 


Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD 


Info-Package R - - - - = = = m* - = 
Recv-Info R - m - m - o o M = o 
Recv-Info 2xx - - - o** — = Q***— - o*** 
Recv-Info lxx - P: - o** — - - - = c 
Recv-Info 469 -= - - - - = - m* = - 
Recv-Info r ES - - O - - O = a o 


Header field where SUB NOT RFR 


Info-Package R - - B 


Recv-Info R — — EE 
Recv-Info 2xx = = = 
Recv-Info lxx - - - 
Recv-Info 469 7 ui = 
Recv-Info Y — — — 


Table 2: INFO-Related Header Fields 


The support and usage of the Info-Package and Recv-Info header fields 
are not applicable to UAs that only support legacy INFO usages. 


"m Not applicable to INFO requests and responses associated with 
legacy INFO usages. 


** Mandatory in at least one reliable 18x/2xx response, if sent, to 
the INVITE request, if the associated INVITE request contained a 
Recv-Info header field. 


*** Mandatory if the associated request contained a Recv-Info header 
field. 


As defined in Section 20 of RFC 3261, a "mandatory" header field MUST 
be present in a request, and MUST be understood by the UAS receiving 
the request. 

7.2.  Info-Package Header Field 
This document adds "Info-Package" to the definition of the element 


"message-header" in the SIP message grammar [RFC3261]. Section 4 
describes the Info-Package header field usage. 
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For the purposes of matching Info Package types indicated in 
Recv-Info with those in the Info-Package header field value, one 
compares the Info-package-name portion of the Info-package-type 
portion of the Info-Package header field octet by octet with that of 
the Recv-Info header field value. That is, the Info Package name is 
case sensitive.  Info-package-param is not part of the comparison- 
checking algorithm. 


This document does not define values for Info-Package types. 
Individual Info Package specifications define these values. 


7.3.  Recv-Info Header Field 
This document adds Recv-Info to the definition of the element 
"message-header" in the SIP message grammar [RFC3261]. Section 5 
describes the Recv-Info header field usage. 

8. Info Package Considerations 

8.1. General 
This section covers considerations to take into account when deciding 


whether the usage of an Info Package is appropriate for transporting 
application information for a specific use-case. 


8.2. Appropriateness of Info Package Usage 


When designing an Info Package, for application level information 
exchange, it is important to consider: is signaling, using INFO 
requests, within a SIP dialog, an appropriate mechanism for the use- 
case? Is it because it is the most reasonable and appropriate 
choice, or merely because "it's easy"? Choosing an inappropriate 
mechanism for a specific use-case can cause negative effects in SIP 
networks where the mechanism is used. 


8.3. INFO Request Rate and Volume 


INFO messages differ from many other sorts of SIP messages in that 
they carry application information, and the size and rate of INFO 
messages are directly determined by the application. This can cause 
application information traffic to interfere with other traffic on 
that infrastructure, or to self-interfere when data rates become too 
high. 


There is no default throttling mechanism for INFO requests. Apart 
from the SIP session establishment, the number of SIP messages 
exchanged during the lifetime of a normal SIP session is rather 
small. 
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Some applications, like those sending Dual-Tone Multi-Frequency 
(DTMF) tones, can generate a burst of up to 20 messages per second. 
Other applications, like constant GPS location updates, could 
generate a high rate of INFO requests during the lifetime of the 
invite dialog usage. 


A designer of an Info Package, and the application that uses it, need 
to consider the impact that the size and the rate of the INFO 
messages have on the network and on other traffic, since it normally 
cannot be ensured that INFO messages will be carried over a 
congestion-controlled transport protocol end-to-end. Even if an INFO 
message is sent over such a transport protocol, a downstream SIP 
entity might forward the message over a transport protocol that does 
not provide congestion control. 


Furthermore, SIP messages tend to be relatively small, on the order 
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 
exchange of bulk data beyond these limits, especially if the headers 
plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. 
Appropriate mechanisms for such traffic include the Hypertext 
Transfer Protocol (HTTP) [RFC2616], the Message Session Relay 
Protocol (MSRP) [RFC4975], or other media plane data transport 
mechanisms. 


RFC 5405 [RFC5405] provides additional guidelines for applications 
using UDP that may be useful background reading. 


8.4. Alternative Mechanisms 

8.4.1. Alternative SIP Signaling Plane Mechanisms 

8.4.1.1. General 
This subsection describes some alternative mechanisms for 
transporting application information on the SIP signaling plane, 
using SIP messages. 

rd Las SUBSCRIBE/NOTIFY 
An alternative for application level interaction is to use 
subscription-based events [RFC3265] that use the SIP SUBSCRIBE and 
NOTIFY methods. Using that mechanism, a UA requests state 


information, such as keypad presses from a device to an application 
server, or key-map images from an application server to a device. 
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Event Packages [RFC3265] perform the role of disambiguating the 
context of a message for subscription-based events. The Info Package 
mechanism provides similar functionality for application information 
exchange using invite dialog usages [RFC5057]. 


While an INFO request is always part of, and shares the fate of, an 
existing invite dialog usage, a SUBSCRIBE request creates a separate 
dialog usage [RFC5057], and is normally sent outside an existing 
dialog usage. 


The subscription-based mechanism can be used by SIP entities to 
receive state information about SIP dialogs and sessions, without 
requiring the entities to be part of the route set of those dialogs 
and sessions. 


As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 
and back-to-back user agents (B2BUAs), the resource impact caused by 
the subscription dialogs needs to be considered. The number of 
subscription dialogs per user also needs to be considered. 


As for any other SIP-signaling-plane-based mechanism for transporting 
application information, the SUBSCRIBE/NOTIFY messages can put a 
significant burden on intermediate SIP entities that are part of the 
dialog route set, but do not have any interest in the application 
information transported between the end users. 


8.4.1.3. MESSAGE 


The MESSAGE method [RFC3428] defines one-time instant message 
exchange, typically for sending MIME contents for rendering to the 
user. 


8.4.2. Media Plane Mechanisms 
8.4.2.1. General 


In SIP, media plane channels associated with SIP dialogs are 
established using SIP signaling, but the data exchanged on the media 
plane channel does not traverse SIP signaling intermediates, so if 
there will be a lot of information exchanged, and there is no need 
for the SIP signaling intermediaries to examine the information, it 
is recommended to use a media plane mechanism, rather than a SIP- 
Signaling-based mechanism. 


A low-latency requirement for the exchange of information is one 
strong indicator for using a media channel.  Exchanging information 
through the SIP routing network can introduce hundreds of 
milliseconds of latency. 
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8.4.2.2. MRCP 


One mechanism for media plane exchange of application data is the 
Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2], where a 
media plane connection-oriented channel, such as a Transmission 
Control Protocol (TCP) [RFC0793] or Stream Control Transmission 
Protocol (SCTP) [RFC4960] stream is established. 


8.4.2.3. MSRP 


MSRP [RFC4975] defines session-based instant messaging as well as 
bulk file transfer and other such large-volume uses. 


8.4.3.  Non-SIP-Related Mechanisms 


Another alternative is to use a SIP-independent mechanism, such as 
HTTP [RFC2616]. In this model, the UA knows about a rendezvous point 
to which it can direct HTTP requests for the transfer of information. 
Examples include encoding of a prompt to retrieve in the SIP Request 
URI [RFC4240] or the encoding of a SUBMIT target in a VoiceXML 
[W3C.REC-voicexm121-20070619] script. 


9. Syntax 
9.1. General 


This section describes the syntax extensions to the ABNF syntax 
defined in RFC 3261 required for the INFO method, and adds 
definitions for the Info-Package and Recv-Info header fields. The 
previous sections describe the semantics. The ABNF defined in this 
specification is conformant to RFC 5234 [RFC5234]. 


9.2. ABNF 
INFOm = $x49.4E.46.4F ; INFO in caps 
Method =/ INFOm 
message-header =/ (Info-Package / Recv-Info) CRLF 
Info-Package = "Info-Package" HCOLON Info-package-type 
Recv-Info = "Recv-Info" HCOLON [Info-package-list] 
Info-package-list = Info-package-type *( COMMA Info-package-type ) 
Info-package-type = Info-package-name *( SEMI Info-package-param ) 
Info-package-name = token 
Info-package-param =  generic-param 
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10. Info Package Requirements 
10.1. General 


This section provides guidance on how to define an Info Package, and 
what information needs to exist in an Info Package specification. 


If, for an Info Package, there is a need to extend or modify the 
behavior described in this document, that behavior MUST be described 
in the Info Package specification. It is bad practice for Info 
Package specifications to repeat procedures defined in this document, 
unless needed for purposes of clarification or emphasis. 


Info Package specifications MUST NOT weaken any behavior designated 
with "SHOULD" or "MUST" in this specification. However, Info Package 
Specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 
requirements to "MUST" if applications associated with the Info 
Package require it. 


Info Package specifications MUST address the issues defined in the 
following subsections, or document why an issue is not applicable to 
the specific Info Package. 


Section 8.4 describes alternative mechanisms, which should be 
considered as part of the process for solving a specific use-case, 
when there is a need for transporting application information. 


10.2. Overall Description 


The Info Package specification MUST contain an overall description of 
the Info Package: what type of information is carried in INFO 
requests associated with the Info Package, and for what types of 
applications and functionalities UAs can use the Info Package. 


If the Info Package is defined for a specific application, the Info 
Package specification MUST state which application UAs can use the 
Info Package with. 


10.3. Applicability 
The Info Package specification MUST describe why the Info Package 
mechanism, rather than some other mechanism, has been chosen for the 


Specific use-case to transfer application information between SIP 
endpoints. Common reasons can be a requirement for SIP proxies or 
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10. 


10. 


back-to-back user agents (B2BUAs) to see the transported application 
information (which would not be the case if the information was 
transported on a media path), or that it is not seen as feasible to 
establish separate dialogs (subscription) in order to transport the 
information. 


Section 8 provides more information and describes alternative 
mechanisms that one should consider for solving a specific use-case. 


4. Info Package Name 


The Info Package specification MUST define an Info Package name, 
which UAs use as a header field value (e.g., "infoX") to identify the 
Info Package in the Recv-Info and Info-Package header fields. The 
header field value MUST conform to the ABNF defined in Section 9.2. 


The Info Package mechanism does not support package versioning. 
Specific Info Package message body payloads can contain version 
information, which is handled by the applications associated with the 
Info Package. However, such a feature is outside the scope of the 
generic Info Package mechanism. 


NOTE: Even if an Info Package name contains version numbering 
(e.g., foo v2), the Info Package mechanism does not distinguish a 
version number from the rest of the Info Package name. 


5. Info Package Parameters 


The Info Package specification MAY define Info Package parameters, 
which can be used in the Recv-Info or Info-Package header fields, 
together with the header field value that indicates the Info Package 
name (see Section 10.4). 


The Info Package specification MUST define the syntax and semantics 
of the defined parameters. In addition, the specification MUST 
define whether a specific parameter is applicable to only the 
Recv-Info header field, only the Info-Package header field, or to 
both. 


By default, an Info Package parameter is only applicable to the Info 
Package for which the parameter has been explicitly defined. 
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Info Package parameters defined for specific Info Packages can share 
the name with parameters defined for other Info Packages, but the 
parameter semantics are specific to the Info Package for which they 
are defined. However, when choosing the name of a parameter, it is 
RECOMMENDED to not use the same name as an existing parameter for 
another Info Package, if the semantics of the parameters are 
different. 


6. SIP Option-Tags 


The Info Package specification MAY define SIP option-tags, which can 
be used as described in RFC 3261. 


The registration requirements for option-tags are defined in RFC 5727 
[RFC5727]. 


7. INFO Message Body Parts 


The Info Package specification MUST define which message body part 
MIME types are associated with the Info Package. The specification 
MUST either define those body parts, including the syntax, semantics, 
and MIME type of each body part, or refer to other documents that 
define the body parts. 


If multiple message body part MIME types are associated with an Info 
Package, the Info Package specification MUST define whether UAs need 
to use multipart body parts, in order to include multiple body parts 
in a single INFO request. 


8. Info Package Usage Restrictions 


If there are restrictions on how UAs can use an Info Package, the 
Info Package specification MUST document such restrictions. 


There can be restrictions related to whether UAs are allowed to send 
overlapping (outstanding) INFO requests associated with the Info 
Package, or whether the UA has to wait for the response for a 
previous INFO request associated with the same Info Package. 


There can also be restrictions related to whether UAs need to support 
and use other SIP extensions and capabilities when they use the Info 
Package, and if there are restrictions related to how UAs can use the 
Info Package together with other Info Packages. 
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As the SIP stack might not be aware of Info Package specific 
restrictions, it cannot be assumed that overlapping requests would be 
rejected. As defined in Section 4.2.2, UAs will normally send a 200 
(OK) response to an INFO request. The application logic associated 
with the Info Package needs to handle situations where UAs do not 
follow restrictions associated with the Info Package. 


10.9. Rate of INFO Requests 
If there is a maximum or minimum rate at which UAs can send INFO 


requests associated with the Info Package within a dialog, the Info 
Package specification MUST document the rate values. 


If the rates can vary, the Info Package specification MAY define Info 
Package parameters that UAs can use to indicate or negotiate the 
rates. Alternatively, the rate information can be part of the 
application data information associated with the Info Package. 


10.10. Info Package Security Considerations 


If the application information carried in INFO requests associated 
with the Info Package requires a certain level of security, the Info 
Package specification MUST describe the mechanisms that UAs need to 
use in order to provide the required security. 


If the Info Package specification does not require any additional 
security, other than what the underlying SIP protocol provides, this 
MUST be stated in the Info Package specification. 


NOTE: In some cases, it may not be sufficient to mandate Transport 
Layer Security (TLS) [RFC5246] in order to secure the Info Package 
payload, since intermediaries will have access to the payload, and 
because beyond the first hop, there is no way to assure subsequent 
hops will not forward the payload in clear text. The best way to 
ensure secure transport at the application level is to have the 
security at the application level. One way of achieving this is 
to use end-to-end security techniques such as Secure/Multipurpose 
Internet Mail Extensions (S/MIME) [RFC5751]. 


10.11. Implementation Details 
It is strongly RECOMMENDED that the Info Package specification define 
the procedure regarding how implementors shall implement and use the 


Info Package, or refer to other locations where implementors can find 
that information. 
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TI: 


II. 


1.1 


IT. 


NOTE: Sometimes an Info Package designer might choose to not 
reveal the details of an Info Package. However, in order to allow 
multiple implementations to support the Info Package, Info Package 
designers are strongly encouraged to provide the implementation 
details. 


12. Examples 
It is RECOMMENDED that the Info Package specification provide 
demonstrative message flow diagrams, paired with complete messages 


and message descriptions. 


Note that example flows are by definition informative, and do not 
replace normative text. 


IANA Considerations 
1. Update to Registration of SIP INFO Method 
IANA updated the existing registration in the "Methods and Response 


Codes" registry under "Session Initiation Protocol (SIP) Parameters" 
from: 


Method: INFO 
Reference: [RFC2976] 
to: 

Method: INFO 
Reference: [RFC6086] 


-2. Registration of the Info-Package Header Field 


IANA added the following new SIP header field in the "Header Fields" 
registry under "Session Initiation Protocol (SIP) Parameters". 


Header Name: Info-Package 
Compact Form: (none) 
Reference: [RFC6086] 


3. Registration of the Recv-Info Header Field 


IANA added the following new SIP header field in the "Header Fields" 
registry under "Session Initiation Protocol (SIP) Parameters". 


Header Name: Recv-Info 
Compact Form: (none) 
Reference: [RFC6086] 
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11.4. Creation of the Info Packages Registry 


IANA created the following registry under "Session Initiation 
Protocol (SIP) Parameters": 


Info Packages 
Note to the reviewer: 


The policy for review of Info Packages is "Specification 
Required", as defined in [RFC5226]. This policy was selected 
because Info Packages re-use an existing mechanism for transport 
of arbitrary session-associated data within SIP; therefore, new 
Info Packages do not require the more extensive review required by 
Specifications that make fundamental protocol changes. However, 
the reviewer is expected to verify that each Info Package 
registration is in fact consistent with this definition. Changes 
to the SIP protocol and state machine are outside of the allowable 
Scope for an Info Package and are governed by other procedures 
including RFC 5727 and its successors, if any. 


The following data elements populate the Info Packages Registry. 
o Info Package Name: The Info Package Name is a case-sensitive 
token. In addition, IANA shall not register multiple Info Package 


names that have identical case-insensitive values. 


o Reference: A reference to a specification that describes the Info 
Package. 


The initial population of this table shall be: 
Name Reference 
11.5. Registration of the Info-Package Content-Disposition 
IANA added the following new header field value to the "Mail Content 
Disposition Values" registry under "Mail Content Disposition Values 
and Parameters". 
Name: info-package 
Description: The body contains information associated with an 


Info Package 
Reference: RFC6086 


Holmberg, et al. Standards Track [Page 25] 


RFC 6086 INFO Framework January 2011 


11.6. SIP Response Code 469 Registration 


IANA registered the following new response code in the "Session 
Initiation Protocol (SIP) Parameters" -- "Response Codes" registry. 


Response Code: 469 
Default Reason Phrase: Bad Info Package 
Reference: RFC6086 


12. Examples 


12.1. Indication of Willingness to Receive INFO Requests for Info 
Packages 


12.1.1. Initial INVITE Request 


The UAC sends an initial INVITE request, where the UAC indicates that 
it is willing to receive INFO requests for Info Packages P and R. 


INVITE sip:bobGexample.com SIP/2.0 

Via: SIP/2.0/TCP pc33.example.com;branch-z9hG4bK776 
Max-Forwards: 70 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.com>;tag=1928301774 
Call-ID: a84b4c76e66710@pc33.example.com 

CSeq: 314159 INVITE 

Recv-Info: P, R 

Contact: <sip:alice@pc33.example.com> 
Content-Type: application/sdp 

Content-Length: 
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The UAS sends a 200 (OK) response back to the UAC, where the UAS 
indicates that it is willing to receive INFO requests for Info 
Packages R and T. 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pc33.example.com;branch-z9hG4bK776; 
received-192.0.2.1 

To: Bob <sip:bob@example.com>;tag=a6c85cf 

From: Alice «sip:aliceGexample.com»;tag-1928301774 

Call-ID: a84b4c76e66710@pc33.example.com 

CSeq: 314159 INVITE 

Contact: <sip:bob@pc33.example.com> 

Recv-Info: R, T 

Content-Type: application/sdp 

Content-Length: 


The UAC sends an ACK request. 


ACK sip:bob@pc33.example.com SIP/2.0 

Via: SIP/2.0/TCP pc33.example.com; branch=z9hG4bK754 
Max-Forwards: 70 

To: Bob <sip:bob@example.com>;tag=a6c85cf 

From: Alice <sip:alice@example.com>; tag=1928301774 
Call-ID: a84b4c76e66710@pc33.example.com 

CSeq: 314159 ACK 

Content-Length: 0 


12.1.2. Target Refresh 


The UAC sends an UPDATE request within the invite dialog usage, where 
the UAC indicates (using an empty Recv-Info header field) that it is 
not willing to receive INFO requests for any Info Packages. 


UPDATE sip:bob@pc33.example.com SIP/2.0 

Via: SIP/2.0/TCP pc33.example.com;branch-z9hG4bK776 
Max-Forwards: 70 

To: Bob <sip:bob@example.com>;tag=a6c85cf 

From: Alice <sip:alice@example.com>;tag=1928301774 
Call-ID: a84b4c76e66710@pc33.example.com 

CSeq: 314163 UPDATE 

Recv-Info: 

Contact: <sip:alice@pc33.example.com> 
Content-Type: application/sdp 

Content-Length: 
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The UAS sends a 200 (OK) response back to the UAC, where the UAS 
indicates that it is willing to receive INFO requests for Info 
Packages R and T. 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pc33.example.com;branch-z9hG4bK893; 
received-192.0.2.1 

To: Bob <sip:bob@example.com>;tag=a6c85cf 

From: Alice <sip:alice@example.com>;tag=1928301774 

Call-ID: a84b4c76e66710@pc33.example.com 

CSeq: 314163 INVITE 

Contact: <sip:alice@pc33.example.com> 

Recv-Info: R, T 

Content-Type: application/sdp 

Content-Length: 


12.2. INFO Request Associated with Info Package 
12.2.1. Single Payload 
The UA sends an INFO request associated with Info Package "foo". 


INFO sip:alice@pc33.example.com SIP/2.0 

Via: SIP/2.0/UDP 192.0.2.2:5060;branch-z9hG4bKnabcdef 
To: Bob <sip:bob@example.com>;tag=a6c85cf 

From: Alice <sip:alice@example.com>;tag=1928301774 
Call-Id: a84b4c76e66710@pc33.example.com 

CSeq: 314333 INFO 

Info-Package: foo 

Content-type: application/foo 

Content-Disposition: Info-Package 

Content-length: 24 


I am a foo message type 

12.2.2. Multipart INFO 

12.2.2.1.  Non-Info Package Body Part 
SIP extensions can sometimes add body part payloads into an INFO 
request, independent of the Info Package. In this case, the Info 
Package payload gets put into a multipart MIME body, with a 


Content-Disposition header field that indicates which body part is 
associated with the Info Package. 
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INFO sip:alice@pc33.example.com SIP/2.0 

Via: SIP/2.0/UDP 192.0.2.2:5060;branch-z9hG4bKnabcdef 
To: Alice <sip:alice@example.net>;tag=1234567 

From: Bob <sip:bob@example.com>;tag=abcdefg 

Call-Id: a84b4c76e66710@pc33.example.com 

CSeq: 314400 INFO 

Info-Package: foo 

Content-Type: multipart/mixed; boundary="theboundary" 
Content-Length: 


--theboundary 
Content-Type: application/mumble 


«mumble stuff» 


--theboundary 

Content-Type: application/foo-x 
Content-Disposition: Info-Package 
Content-length: 59 


I am a foo-x message type, and I belong to Info Package foo 
--theboundary-- 


12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body 
Part 


Multiple body part payloads can be associated with a single Info 
Package. In this case, the body parts are put into a multipart MIME 
body, with a Content-Disposition header field that indicates which 
body part is associated with the Info Package. 


INFO sip:alice@pc33.example.com SIP/2.0 

Via: SIP/2.0/UDP 192.0.2.2:5060;branch-z9hG4bKnabcdef 
To: Alice <sip:alice@example.net>; tag=1234567 

From: Bob «sip:bobüexample.com»;tag-abcdefg 

Call-Id: a84b4c76e66710@pc33.example.com 

CSeq: 314423 INFO 

Info-Package: foo 

Content-Type: multipart/mixed; boundary="theboundary" 
Content-Disposition: Info-Package 

Content-Length: 


--theboundary 


Content-Type: application/foo-x 
Content-length: 59 
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I am a foo-x message type, and I belong to Info Package foo 
«mumble stuff» 

--theboundary 

Content-Type: application/foo-y 

Content-length: 59 


I am a foo-y message type, and I belong to Info Package foo 
--theboundary-- 


.2.2.3. Info Package with Single Body Part inside Multipart Body Part 


The body part payload associated with the Info Package can have a 
Content-Disposition header field value other than "Info-Package". In 
this case, the body part is put into a multipart MIME body, with a 
Content-Disposition header field that indicates which body part is 
associated with the Info Package. 


INFO sip:alice@pc33.example.com SIP/2.0 

Via: SIP/2.0/UDP 192.0.2.2:5060;branch-z9hG4bKnabcdef 
To: Alice <sip:alice@example.net>;tag=1234567 

From: Bob <sip:bob@example.com>; tag=abcdefg 

Call-Id: a84b4c76e66710@pc33.example.com 

CSeq: 314423 INFO 

Info-Package: foo 

Content-Type: multipart/mixed; boundary="theboundary" 
Content-Disposition: Info-Package 

Content-Length: 


--theboundary 

Content-Type: application/foo-x 
Content-Disposition: icon 
Content-length: 59 


I am a foo-x message type, and I belong to Info Package foo 
--theboundary-- 


Security Considerations 


By eliminating multiple usages of INFO messages without adequate 
community review, and by eliminating the possibility of rogue SIP UAs 
confusing another UA by purposely sending unrelated INFO requests, we 
expect this document's clarification of the use of INFO to improve 
the security of the Internet. While rogue UAs can still send 
unrelated INFO requests, this mechanism enables the UAS and other 
security devices to associate INFO requests with Info Packages that 
have been negotiated for a session. 
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If the content of the Info Package payload is private, UAs will need 
to use end-to-end encryption, such as S/MIME, to prevent access to 
the content. This is particularly important, as transport of INFO is 
likely not to be end-to-end, but through SIP proxies and back-to-back 
user agents (B2BUAs), which the user may not trust. 


The INFO request transports application level information. One 
implication of this is that INFO messages may require a higher level 
of protection than the underlying SIP dialog signaling. In 
particular, if one does not protect the SIP signaling from 
eavesdropping or authentication and repudiation attacks, for example 
by using TLS transport, then the INFO request and its contents will 
be vulnerable as well. Even with SIP/TLS, any SIP hop along the path 
from UAC to UAS can view, modify, or intercept INFO requests, as they 
can with any SIP request. This means some applications may require 
end-to-end encryption of the INFO payload, beyond, for example, hop- 
by-hop protection of the SIP signaling itself. Since the application 
dictates the level of security required, individual Info Packages 
have to enumerate these requirements. In any event, the Info Package 
mechanism described by this document provides the tools for such 
Secure, end-to-end transport of application data. 


One interesting property of Info Package usage is that one can re-use 
the same digest-challenge mechanism used for INVITE-based 
authentication for the INFO request. For example, one could use a 
quality-of-protection (qop) value of authentication with integrity 
(auth-int), to challenge the request and its body, and prevent 
intermediate devices from modifying the body. However, this assumes 
the device that knows the credentials in order to perform the INVITE 
challenge is still in the path for the INFO request, or that the far- 
end UAS knows such credentials. 
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